IBIS Macromodel Task Group Meeting date: 10 September 2019 Members (asterisk for those attending): ANSYS: Dan Dvorscak * Curtis Clark Cadence Design Systems: Ambrish Varma Ken Willis Kumar Keshavan Intel: * Michael Mirmak Keysight Technologies: * Fangyi Rao * Radek Biernacki Ming Yan Stephen Slater Maziar Farahmand Mentor, A Siemens Business: * Arpad Muranyi Micron Technology: * Randy Wolff * Justin Butterfield SiSoft (Mathworks): * Walter Katz Mike LaBonte SPISim: * Wei-hsing Huang Teraspeed Labs: * Bob Ross The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - None ------------- Review of ARs: - Walter to draft an alternate proposal for BIRD198.1. - Done. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: Arpad asked for any comments or corrections to the minutes of the September 03 meeting. Michael M. moved to approve the minutes. Walter seconded the motion. There were no objections. ------------- New Discussion: Jitter HF/LF components and jitter amplification: Michael M. noted that it will be a while before he has a new version of this proposal. The next update will be in the form of a new BIRD draft, and it will pursue a spectral distribution approach. Michael moved to put this topic in the Tabled Topics section. Arpad seconded. There were no objections. DC_Offset BIRD: Walter moved to table this topic too, because it is potentially related to the BCI for statistical topic. Fangyi asked how they are related. Walter said that the DDR5 DQ Write protocol discussion would explain the connection. It might be useful to use the output value of DC_Offset to return the VREFDQ value that the Rx model ends up using after the training is complete. Michael M. seconded the motion. There were no objections. BIRD198.1: Walter reviewed his "BIRD 198 Response" presentation. Walter noted that he thought introduction of a new Model_type was unnecessarily complicated. He proposed a new [PDN Model] keyword that would contain the series R and C, a parallel Rleak, and two bus labels (or signal_names) that it connected. At the [Component] level, an [On Die PDN Models] section could contain multiple [PDN Model]s. Walter noted that he agreed that this type of simplified RC model would be good to have for PDN modeling. Walter posed the following questions: - Do we need bus_labels, or are signal_names enough? - Why do we need the concept of [Model Selector]s in this case? - Models and [Model Selector]s were designed for Pins, which are configurable. - What does it mean to have selectable PDN models? - This proposal deals with supply rails not Pins. - Do we need the amplitude version of typ, min, max, or can we just use the process corner version? - How should this interact with BIRD189 (rules for the interaction)? - Always instantiating both is the easiest rule to define and understand. - One-or-the-other is the second easiest. - Complicated overlapping usage rules are hard to understand. Arpad noted that he thought the authors had added Model Selector simply because they had added a new Model_type, and [Model Selector]s choose models. He noted that he liked Walter's attempt to simplify things, but he thought we might want to keep the magnitude and process corner versions of typ, min, max as the authors intended. Arpad noted that there might be some technical fine tuning necessary with Walter's proposal (keyword vs. Sub-param, etc.). Walter said that he had focused on proposing something similar to what the authors had, and there could be fine tuning. Bob said [Model Selector] support isn't strictly necessary, since BIRD198.1 proposes a new Model_type, and we already have the Series and Series_Switch Model_types that aren't used with [Model Selector]s. Bob said he thought Walter's proposal was promising. Bob said he wasn't sure how a corner for an on-die decoupling model would be associated with a semiconductor process corner. Arpad said it might depend on how it's implemented. If it's implemented with metal layers it might be independent of the silicon process corner, but if it's implemented as a transistor it might depend on it. Walter said that we could add process corner and magnitude options to his proposal. Walter said the concept of [Model Selector] isn't needed here. It's typically used for things like selecting different on-die termination impedances. What does it mean to have two different models between VDDA and VSS? Arpad said it might be used for user convenience, e.g., to switch between a per DQ decoupling model or an overall decoupling model. It might also be used to allow what-if analyses where the models may not match physical reality but are useful for finding a solution space. Bob noted that we could add a new keyword if we needed a different type of Model Selector. He said he agreed with Walter that Models and Model Selectors are Pin focused and this proposal is bus_label focused. Radek asked about the rules for interaction with BIRD189 models. Walter noted instantiated, then they could plan accordingly. You could put simple parallel that if a model maker knew both the BIRD189 model and this new model would be terminations in this new model and more complicated series distributions in a BIRD189 model if necessary. Randy noted that the parser would not have any complicated rules to check if we went with the approach of instantiating both model types. Randy took the AR to draft a response to the authors containing: 1. Description of Walter's proposal. 2. Question about the intended use of Model_Selector. 3. Request for feedback on rules for interaction with BIRD189. Enabling Back-channel in Statistical Mode: Walter asked for questions or comments on the previous week's presentation. Fangyi asked what IR matrix is passed to the proposed new function. Walter said it was the same IR passed to the Init() function. Fangyi asked if the IR returned by the Rx function gets passed back to the Tx. Walter said it did not. Walter said that each iteration was just running the entire channel over again with a different set of tap coefficients. Walter shared a presentation about developing a DDR5 DQ Write Protocol. Walter noted that his goal was to describe the issues to be resolved. He hoped we could then attract input from other DDR5 IC vendors. - Overview (slide 2) - DDR5 DQ Write Protocol - How does the hardware train? - What can the Tx tell the Rx? - What can the Rx tell the Tx? - Generic Tx N-Tap FFE protocol - Hardware training diagram (slide 3) - Controller (Tx) trains the memory (Rx). - What can it set? - VREFDQ register. - Gain register. - Tap registers. - Looking for target BER of 1e-16 in hardware training isn't practical. - Controller sweeps VREFDQ up and down until errors occur, then it chooses something in the middle. - Controller also varies the phase of DQS and looks for errors, then it chooses something in the middle. - Hardware likely looking for a BER between 1e-3 and 1e-5 when it's sweeping and looking for errors. - What can the Tx tell the Rx? (slide 4) - The VREFDQ, Gain, and Tap register settings. - JEDEC standard specifies the min and max values. - What can the Rx tell the Tx? (slide 5) - Value of VREFDQ (Volts) - This is the value that could be returned as the output value of DC_Offset. - Value of Gain. - Value of each DFE Tap (Volts) - Eye Metric information, possibilities include: - Eye Height, Eye Width, Eye area, COM at a specified BER. - The IR at the latch. - The Tx may also need to know additional impairment info (RxDj, etc.) Walter noted that the Eye Metric decision is critical. If the Rx computes the metric and returns it, not much data is exchanged. If we have to pass the IR at the latch back to the Tx so it can compute the metric, then it could affect performance. BIRD147 had always assumed the Rx would do the training, so data exchange between the Tx and Rx was minimal. BIRD147 implemented a simple file I/O approach for GetWave() training. If we have to pass the IR at the latch back to the Tx, then the file gets larger and affects performance. Walter noted that Fangyi had raised a point about training nibbles instead of individual lines. Walter said we could create an additional protocol to allow 4, 8, etc. bits to be trained simultaneously. For now, Walter wanted to focus on a single-bit DQ Write protocol. Fangyi (referring to slide 5) noted that in the physical system the controller (Tx) probably only gets an eye metric back. Walter said that the controller sweeps VREFDQ and finds out when errors occur, that's the metric for hardware training. Fangyi agreed. Walter noted that when developing this BCI protocol we can be smarter than the hardware and have access to more information (e.g., the IR at the latch) if necessary. Walter asked for ways to get more contributors to this discussion before we go into further details. He asked if there was a way to get these presentations in front of a JEDEC meeting. Michael M. and Randy said they would each do some research internally and see if they could identify any possible audiences. - Walter: Motion to adjourn. - Michael M.: Second. - Arpad: Thank you all for joining. AR: Randy to draft a response to the BIRD198 authors. ------------- Next meeting: 17 September 2019 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives